home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000050_jcliffor@is-4.stern.nyu.edu _Thu Mar 25 15:18:20 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  4KB
  1. Received: from IS-4.STERN.NYU.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP
  2.     id AA07356; Thu, 25 Mar 1993 13:11:04 MST
  3. Received: by is-4.stern.nyu.edu (4.1/1.34)
  4.     id AA24453; Thu, 25 Mar 93 15:18:23 EST
  5. Date: Thu, 25 Mar 93 15:18:20 EST
  6. From: Jim Clifford <jcliffor@is-4.stern.nyu.edu>
  7. To: tsql@cs.arizona.edu
  8. Subject: Benchmark Schema and Queries
  9. Message-Id: <CMM.0.90.2.733090700.jcliffor@is-4.stern.nyu.edu>
  10.  
  11. I have been thinking some more about some of the issues that have been
  12. raised in this forum with respect to the development of a benchmark schema
  13. and set of queries. I thought it time to post.
  14.  
  15. First, Kalua and Robertson's message expressed many sentiments that I share.
  16.  
  17. Basically, I do not feel that there is much to be gained from leaving
  18. out of the schema -- in the name of a "phased approach" -- semantic
  19. aspects which seem to be universally regarded as important in a
  20. temporal database.  However, I also agree with Rick Snodgrass' comment
  21. that we do not need to have too much "functional redundancy."
  22.  
  23. It seems to me that a good way to proceed would be to first 
  24. try to come up with the "functional" (or "semantic") aspects that we
  25. want (and can agree) to include, and then come up with an example
  26. schema, rather than starting with the schema.
  27.  
  28. Here is a list of  what I gather to be the aspects on the table:
  29.  
  30. (1) single-valued, time-varying attributes that change
  31. discretely over time,  e.g., SALARY
  32.  
  33. (2) single-valued, time-varying attributes that change
  34. continuously over time,  e.g., TEMPERATURE
  35.  
  36. (3) single-valued, time-invariant attributes, e.g. BLOODTYPE (instead
  37. of GENDER), as suggested in (my half of) Clifford, J. and Tansel, A.
  38. ``Towards an Algebra of Historical Relational Databases,'' {\em Proc.
  39. ACM SIGMOD}, Austin, 1985, 247-265.
  40.  
  41. (4) single-valued, so-called (I still hate this term) "user-defined"
  42. temporal attribute, e.g.  BIRTHDATE
  43.  
  44. (5) multivalued, time-varying attributes: e.g., SKILLS
  45.  
  46.  
  47. ***************************************************************************
  48. Some of the other issues raised seem to me to relate to the features of
  49. the QUERY LANGUAGE, rather than the SCHEMA:
  50.  
  51. (a) aggregates  -- I see no reason not to include examples of these queries
  52.  
  53. (b) multiple references to the same relation in a query -- excluding
  54. this seems completely artificial to me.
  55.  
  56. (c) queries that respect/do not respect  the temporal integrity of
  57. historical values (grouped -vs- ungrouped)  -- again, I see no reason
  58. to exclude these.
  59.  
  60. I guess overall my feeling about the query language is that just about
  61. ANYTHING ought to be allowed,and that when we classify the queries we
  62. will indicate which "semantic features" a particular query is
  63. presupposing are incorporated into the model. Then, if the model has
  64. those features, the query can successfully be answered, otherwise it
  65. may be only partially successfully answered.
  66.  
  67. ***************************************************************************
  68. SOME SEEMINGLY AGREED-UPON ISSUES WITH REGARD TO THE SCHEMA for PHASE I
  69.  
  70. (1) Should not include transaction time
  71.  
  72. (2) Should not include schema-versioning 
  73.  
  74. ***************************************************************************
  75. SOME SEEMINGLY OPEN QUESTIONS WITH REGARD TO THE SCHEMA
  76.  
  77. (I) Is there an example of a multivalued "user-defined" temporal
  78. attribute?
  79.  
  80. I don't know.
  81.  
  82. (II) Should we include a greater variety of time-varying attributes, since it
  83. is well known that the possible relationships between data and time are many.
  84. For example, SALARY (above), is itself an aggregated value (generally over a year),
  85. TEMPERATURE is not. Other types of values are aggregated over different granularities
  86. (e.g., DAILY-SALES VOLUME), etc.
  87.  
  88. I think so, because I think that this is an area that is still in need of
  89. greater understanding.
  90.  
  91. ***************************************************************************
  92.  
  93. I welcome any comments.
  94.  
  95. --jim clifford
  96.  
  97. ************************************************************************
  98. Jim Clifford                                     jclifford@stern.nyu.edu
  99. Associate Professor                              TEL: (212) 998-0803
  100. Department of Information Systems                FAX: (212) 995-4228
  101. Leonard N. Stern School of Business
  102. New York University
  103. Management Education Center
  104. 44 West 4th Street, Suite 9-74
  105. New York, NY 10012-1126
  106. ************************************************************************